Date: Mon, 6 Dec 93 04:30:27 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #137 

To: Ham-Digital 


Ham-Digital Digest Mon, 6 Dec 93 Volume 93 : Issue 137 


Today's Topics: 
HAM-server index file 
KPC-3: Remote Station Gets 'Busy' Replies?? 
MICOR on 9.6kbaud packet? 
PK-88 vs KPC-3 vs DPK-2 
Recent APRS posts from the .ampr net 
TEKK Radios (3 msgs) 
unsubscribe 
Who should use gateways for what (was Re: wb7tpy gateway) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 5 Dec 93 01:35:57 GMT 

From: ogicse!cs.uoregon.edu!sgiblab! pacbell.com!amdahl! grafex! 
ka6etb@network.ucsd.edu 

Subject: HAM-server index file 

To: ham-digital@ucsd.edu 


In <9312022028591.gilbaronwOmn.DLITE@delphi.com> gilbaronwOmn@delphi.com (Gilbert 
Baron) writes: 

>>>Phooey on you Gil! I for one am glad to see the list of files. This 
>>>ham-server is a gold mine of info - I've gotten so many goodies off 


>That is what the index is for. Go and read the index yourself and then get 
>what you need. Don't subject the rest of the network to this. It is not 
>needed and waste time and space and LOTS of money. 


Probably no more costly than the AMSAT or KEPLER info published on a much 
more regular basis. 


Boy, are you gonna be peeved when I get HAM-server set up for PBBS. 


73 de KA6ETB 


Date: Fri, 03 Dec 93 12:26:43 EST 

From: ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!newsserver.jvnc.net! 
yale.edu!news.yale.edu! YaleVM.YCC.Yale.Edu!MIKEN@network.ucsd.edu 

Subject: KPC-3: Remote Station Gets 'Busy' Replies?? 

To: ham-digital@ucsd.edu 


What software are you using with the TNC? 
Miken@yalevm.cis.yale.edu 
N1JIX@N1IIX.AMPR.ORG 

In article <97124@cup. portal .com> 


AllanWS@cup.portal.com (Allan BA Schlaugat) writes: 


>This problem is making me lose more hair than I have on my head! 

> 

>I have a KPC-3 TNC which I use to connect to the local PacketCluster. 

>The cluster sysop set up a script where if the path between the cluster 
>and my location drops and I retry out, the cluster will attempt to reconnect 
>to my TNC. This is how I discovered the 'problem'... 

>With the computer off (a 386 clone), leaving the TNC/radio on, a station 
>cannot connect to my TNC. They receive a x*x*xbusy on their end and I get 
>a *** connect request! Note that the remote station is not trying to 
>access the KA-Node or the mailbox; he is just trying to connect to my 
>normal user ID. When I turn the computer on and boot up my packet software, 
>I get a buffer full of *** connect requests as well as other channel 
>traffic. Stations can now connect to me. It seems that I must keep the 
>computer on with terminal software loaded up but this does not seem right. 
>I have been involved with packet for 3 years and have used the MFJ-1278 
>with no problems. In fact, I cannot reproduce this problem with the 

>MFJ. Some locals suggested CTS/RTS hardware flow control might 

>be at fault here. I have my USERS set at 10 /MAXUSERS at 10 btw. 

>Is there anything I am overlooking here? The KPC-3 is 3 weeks old 

>and I never got this thing to work like the MFJ (KPC firmware is 

>5.1). Any clues?? 

> 

>Thanks 

> 


>Al Schlaugat / allanws@cup.portal.com \ Amateur Radio: N9ISN 


Date: 6 Dec 1993 02:52:08 GMT 

From: nothing.ucsd.edu! brian@network.ucsd.edu 
Subject: MICOR on 9.6kbaud packet? 

To: ham-digital@ucsd.edu 


UHF MICORs work fine at 9600 bps. Just shove the transmitted data stream 
into the modulator, which direct-FMs the offset oscillator. Pick the 
received data off pin 6 of the demodulator chip. As with most 

commercial radios, the IFs are just a tiny bit too narrow for 9600, 

but will work well if the signals are at least a few microvolts. 


A word of caution: UHF mobile Micor output transistors are no longer available. 
These are highly-inefficient early RF devices, and tend to be somewhat 
fragile in repeater service. Pick up a few extra radios for spare parts. 


Also, they're real power wasters. Be sure to have a fan on the heatsink 
if you're going to be using it in repeater or BBS service. 
- Brian 


Date: Thu, 02 Dec 93 18:43:01 MST 

From: mvb.saic.com!unogate!news.service.uci.edu!usc!cs.utexas.edu!asuvax!ennews! 
stat! aznet!dan@network.ucsd.edu 

Subject: PK-88 vs KPC-3 vs DPK-2 

To: ham-digital@ucsd.edu 


rdewan@casbah.acns.nwu.edu (Rajiv Dewan) writes: 


> On a comparison of Pk88, DPK-2 and KPC-3, Bob Nielsen <w6swe@w6swe.tapr.ORG> 
> wrote: 

>> 

> >All three of them run KISS. The DPK-2 is the only one which has 

> >£irmware which is completely compatible with TAPR firmware. Any 

> >of these can be upgraded to ‘open squelch' operation using a 

> >$15.00 kit from TAPR. The PK-88 and DPK-2 both can be adapted to 

> >use external modems, but the KPC-3 cannot. 

Deals 5 

> 

> The KPC-3 comes ready to run "open squelch" right out of the box. AILl 
> it needs are two commands: 

> 

> interface terminal 

> cd software 


THE ONLY PROBLEM IS THAT IT IS SOFTWARE OPEN SQUELCH AND FALSES A GREAT DEAL! 


Rajiv 
aa9ch 
r-dewan@nwu. edu 


VV VV 


Dan 


dan@aznet.stat.com 

Daniel J. Meredith 

Fax - (602) 956-2566 
Voice - (602) 809-0555 


Date: Sun, 5 Dec 1993 18:33:15 GMT 

From: csus.edu!netcom.com! rander@decwrl.dec.com 
Subject: Recent APRS posts from the .ampr net 
To: ham-digital@ucsd.edu 


This post is a relay of some recent traffic on the packet network 
about the APRS. For those who aren't familiar, APRS is the 
"Automatic Packet Reporting System" by WB4APR that allows position 
data from a GPS or LORAN receiver to automatically be sent out by 

a TNC and then displayed on a map display be other stations running 
APRS. 


Date: 04 Dec 93 15:26 

Message-ID: <28974@KA6EYH> 

From: W7KKE@KA6EYH 

To: APRS@ALLCAN 

Subject: New/Modified APRS maps 

Path: KI6GEH!N6IYA! N6QMY ! WA8DRZ!WD6CMU! KAGEYH! KA6EYH 


From: W7KKE@KA6EYH.#NOCAL.CA.USA.NA 
To : APRS@ALLCAN 


I have uploaded some new and updated APRS maps to the KA6EYH LLBBS. This 
BBS can be reached at 415-359-6985. Login with your callsign and use the 
password "COAST". 


The maps are in the APRS directory. This BBS uses standard packet BBS 
commands, plus semi-DOS commands. It supports Xmodem and Ymodem in the 
land-line mode. 


To download a file using Xmodem use the following commands after log-in: 


D - Sets you in FBBDOS mode 

cd APRS - Changes current directory to APRS 
dir - Lists contents of the directory 
XGET filename - Sets up file transfer via Xmodem. 


After you are finished transfering files, 
Exit - Returns to packet BBS mode 
The new/updated maps in the APRS directory are: 


CALIF .MAP - Filled the map shell WB4APR sends with his distribution disk 
with more northern & central California roads. 


CAOBISBO.MAP - Covers south central coast between CA-LA.MAP and 
CAGILROY.MAP 


CA_DALY .MAP - Covers Daly City, San Bruno, Colma, and 
Burlingame, and South San Francisco. 
(Includes corrections from WB6LPG's GPS trips) 


CAFSTRCTY.MAP - Covers Foster City and Redwood Shores area. 
This is expanded from the map on the WB4APRS 
distribution disk in that it includes Redwood 
Shores. 

(Includes corrections from WB6LPG's GPS trips) 


CA_MATEO.MAP - Covers San Mateo, part of Burlingame, San 
Carlos, Belmont, and a bit of Redwood City. 
(Includes corrections from WB6LPG's GPS trips) 


HALFMOON.MAP - Covers from Halfmoon Bay airport south to Pigeon Pt. and 
east to Skyline Blvd. 
(Includes partial corrections from WB6LPG's GPS trips) 
73, Ken W7KKE @ KA6EYH.#NOCAL.CA.USA 


Date: 04 Dec 93 17:43 
Message-ID: <28010@WB3V> 
From: WB4APR@WB3V 


To: APRS@ALLUS 
Subject: APRS Football Tracking Success! 
Path: KI6EH!N6IYA!WD6CMU! KAG6EYH! KA6EYH! WX3K!KI7AE!KQ40K ... 


This year we had three packet/GPS trackers attached to the chase vehicles for 
the Army/Navy game footbal run from Annapolis MD to the Meadowlands outside 
of NY City on 3 Dec. We were able to track the 1 watt 2m devices over the 
full 250 miles! Volunteer packet stations all along the route left their 
TNC's on so that we could use them as digipeaters, and W2HOB put up a 
temporary digi in southern NJ at 600 feet! Using only three hops, the once 
every 2 minute position reports made it all along the route ust fine! 


Lessons learned: ALthough the position reports were very reliable, APRS 
messages to the mobiles often took 10's of minutes to be ACKed (if at all) 
towards the end of the route. This is the same reason that DIGI's are poor 
performers in normal packet. Ii is simple. If there is a 20% chance that a 
packet gets through the 3 digipeater path, then there is only a 4% chance that 
the ACK will get back to the sender! This is one of the main reasons that 
APRS avoids CONNECTED packet and ACKS. (I am working on an improved message 
send capability for APRS that tries to mimimize the need for ACKS) 


Direction finding: With all the vehicles 100 miles out of Annapolis, a stuck 
transmitter in Baltimore jammed the frequency for 2 hours solid. Fortunately 
position reports were still being digipeated forward through the network into 
NJ, and N2CZF was digipeating them out onto the 40m HF APRS net, so that we 
still got the reports! All activity in Annapolis turned toward DFing. In 
minutes we had crossed bearing lines, but as more and more non APRS stations 
got involved the bearings deteriated! Later we found out that some reports 
were given by apartment dwellers moving around in their apartments with HT's 
and telling us which corner of their rooms gave the strongest signal! 
Although APRS plotted all these lines well, there was no real convergence. 
But since there was only one other APRS station on the map anywhere within 10 
miles of the mess of lines, he was not home! When he finally was reached 
several hours later, long after the signal had disappeared, he could find no 
evidence that it was his transmitter. Anyway, as soon as the signal quit, the 
position reports came rolling in and all was well! 


OTHERS: In addition to the GPS equipped chase vehicles, we also saw two other 
APRS GPS vehicles join the fun. N3JLQ was automatic-GPS mobile and N2MSM was 
manually entering his GPS position into his Porta-pkt TNC BText! Both 
stations hill-topped around the area of the entourage so that they could be 
used for digipeating to the big DIGI's... We also saw our first Xcountry APRS 
posit from WB6LPG in California! A total of 55 APRS stations were observed 
during the event and we all had fun! 


Date: Fri, 3 Dec 1993 15:43:34 GMT 


From: newsgate.watson.ibm.com!watnews.watson.ibm.com!sernews!news@uunet.uu.net 
Subject: TEKK Radios 
To: ham-digital@ucsd.edu 


Can anyone tell me about the TEKK 440 based Radios? I know they 
are only 2watts, but are they good performers? Any information 
will be greatly appreciated. 


73, Mike KB4LFH 


Date: Sat, 4 Dec 1993 13:40:38 GMT 

From: butch!netcomsv!netcom.com! fmitch@uunet.uu.net 
Subject: TEKK Radios 

To: ham-digital@ucsd.edu 


Felton Mitchell (fmitch@netcom.com) wrote: 
pica pe ibm.com wrote: 
: Can anyone tell me about the TEKK 440 based Radios? I know they 
: are only 2watts, but are they good performers? Any information 
: will be greatly appreciated. 


: 73, Mike KB4LFH 


: hi mike... the tekk's work great! we are using one with a 20 watt brick 
: for our main 9600 baud backbone node on 446.100... for the price, 

: you can't go wrong... we have ordered 5 more to complete our 

: backbone... we probably will use tthe power amps out of some 

: old commercial gear for a little higher power... 


: the tekk expert is geoff, kd4goe, he is on the ‘net and his 
‘net address is geoffp@netcom.com 


PCuly we. 
: mitch, wa4osr 


oops... forgot to tell you one thing... the tekk's don't like 
12 volts... you have to power them from 10-11 volts max, else 
they aren't frequency stable... they pull such little current 


this is not a problem, just a nusiance... 


mitch, wa4osr 


fmitch@netcom.com 

Felton "Mitch" Mitchell, WA40SR in Mobile, Alabama USA 

205-342-7259 home, 205-476-4100 work, 205-476-0465 FAX 

co-sysop for W4IAX bbs running fbb ... sysop for WA4OSR DxXCluster in Mobile.. 


Date: 6 Dec 1993 02:46:29 GMT 

From: nothing.ucsd.edu! brian@network.ucsd.edu 
Subject: TEKK Radios 

To: ham-digital@ucsd.edu 


The TEKK radio is ok for simple 9600 bps links. The transmitter is 

ok, and shows good modulation response when used with the typical 9600 
bps modem - I've tried the TAPR and KONG, and others report G3RUH modems 
work ok. The RF is more-or-less clean. I'd recommend using a cavity 

or other filter on it in most circumstances, and if it's going to be in 
a place where there are other radios on nearby frequencies (such as at 

a repeater site), a circulator or isolator wouldn't be a bad idea. 


The receiver is only fair. The front-end is easily smashed by strong 
signals, so you need additional selectivity if your site has any other 
transmitters nearby. The IF bandpass filters are not ideal for 9600 
bps, but if you have nice strong signals and reduce the transmitted 
deviation, your digital signal will make it through ok. Performance 
is really poor at 9600 with weak signals, though. 


I don't think I'm going to buy any more of them for our links. Maxar 
and Mitrek radios are available surplus for less and seem to be better. 
- Brian 


Date: 5 Dec 93 18:01:05 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: unsubscribe 

To: ham-digital@ucsd.edu 


Date: Thu, 02 Dec 93 21:45:13 ARG 

From: ucsnews!sol.ctr.columbia.edu!math.ohio-state.edu!news.cyberstore.ca!nwnexus! 
a2i!satlink! burzaco!colla@network.ucsd.edu 

Subject: Who should use gateways for what (was Re: wb7tpy gateway) 

To: ham-digital@ucsd.edu 


winter@apple.com (Patty Winter) writes: 


>In article <1993Nov23.085806.17098@mnemosyne.cs.du.edu>, 

>Jonathan Magee <jmagee@nyx10.cs.du.edu> wrote: 

>>The only use of the internet in ham radio should be to connect ham 
>>stations via worm holes ie only hams can use it. 

> 


Over long haul paths Internet could be considered one heck of a backbone 
provided you can check both the origin and the destination are hams; some 
countries might consider one side not being an amateur illegal, some others 
not. 


Beside that, as far as I know there is no regulations preventing amateurs 
to send mail (unidirectionally) to the Internet world with a contents 
within regulations. 


I can also think in several things from the internet that could also be 
carried legally over packet nets such as software, special bulletins, 
emergency mail, etc; most of them usually served by automatic machines 
and again with contents that could be considered otherwise legal if 
exchanged between two licenced hams over the air. 


To got an Internet hook, even an UUCP downstream feed not always is neither 
cheap nor feasible. 


Date: Sat, 4 Dec 1993 19:40:53 +0000 
From: news.sprintlink.net!demon!djwhome.demon.co.uk!david@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <1993Nov23.163518.13551@hemlock.cray.com>, 
<2d08eo$mi4@wvhpadm1.mentorg.com>, <2d24se$dam@unicorn.ccc.nottingham.ac.uk> 
Subject : Misroutes to Namibia usa.na domain (was: wb7tpy gateway) 


Well it looks from the DNS lookup that what is catching people out is a 
very shallow domain name structure in Namibia. My guess is that there is 
little or no real Internet connectivity in Namibia so there is one mail 


relay which forwards all mail by something like UUCP. Thus a x.na MX 
record is not unreasonable, as nearly all na mail needs to go to the 
same relay and there is no point in recording individual sub-domains; a 
lot of commercial domains do this. I'm not sure about the na MX 
records, but there is nothing technically wrong with them. 


Although the mentorg.com example of dropping the domain name for local 
traffic is largely true, it misses one significant point, which is 
that you should not use top level domain names as subdomain names when 
doing this. 


Actually, in this particular case, there would seem to be a simple 
solution within the domain name system which could avoid this problem. 
All that needs to happen is for Namibia to add an MX record for 
*x.uUSa.na, pointing to a North American Internet to Packet gateway, or a 
bit bucket (but the IP address must be good so that mailers don't try to 
fall back to the *.na address). With the former, as I understand it, 
inbound mail needs human vetting, so a warning can be sent to the 
originator and the mail optionally forwarded into the Packet network. 
Alternatively, the gateway could just bounce it with an appropriate 
message. 


By doing this, at most, only a DNS query has to go to Namibia, and if 
a long time to live is given for the entry any one source of such 
misrouted mail should only rarely need to do this. 


By the way, the logic behind the UK restriction on third party 
traffic partly relates to the historic state monopoly on 
telecommunications and partly to the idea that the radio spectrum is 
commercially valuable, so amateurs, who get access well below the 
market rate for the resource should not be able to compete with 
commercial communication providers. (I think that the US will only 
allow third party traffic when both the countries involved allow it.) 


I am copying this to the DNS administrator and postmaster for na, but to 
fully implement it will need some cooperation from a US gateway. So I 
suggest that you agree as to which gateways should be targets of a 
*.uSa.na MX record and then the administrators of those gateways should 
follow up to the na DNS administrator. 


David Woolley, London, England david@djwhome.demon.co.uk 


End of Ham-Digital Digest V93 #137 
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